OAuth

How Authorization Works over the internet

11 Feb 2017 View Comments
#oauth #programming #API #authorization #SaaS #cloud #computer

You probably heard words like Software as a Service (SaaS) or Cloud. OAuth is the key factor in connecting them all together. Open Authorization (OAuth) is a protocol that allows an application to authenticate against a server as a user, without requiring passwords or any third party server that acts as an identity provider. It uses a token generated by the server and provides how the authorization flows most occur, so that a client, such as a mobile application, can tell the server what user is using the service. In the beginning, there was no standard for authorization hence was required to use username and password everywhere which is a security vulnerability. Then OAuth came along as a standard for authorization. It is an authorization framework that enables a third-party application to obtain a limited access to an HTTP service. It works over HTTP and connects with authorizations for APIs, devices, servers and applications with access tokens rather than using credentials such as username and password.

OAuth Vocabulary

• User - a customer who has an account in both consumer and service provider.
• Consumer - Uses OAuth (Open API) to communicate between service provider.
• Service Provider - Uses OAuth to communicate between consumer to provide service.
• Consumer Key - API key associated with the application. It identifies the client which is the service that is trying to access user’s resource
• Consumer Secret - Password used to authenticate consumer from service provider
• Access Token - Access tokens are credentials used to access protected resources. There is no visible username/password. Token is meant to be the authorization to user’s resource

OAuth Use Case

Below use case is compiled with above vocabulary in mind. Take a close look at how the vocabulary relates to the use case.

1. User submits an authorization request to Consumer, which validates that the User is a legitimate User of its service.
2. Consumer redirects the User to the Service Provider to request access to its resources.
3. Service provider validates the User’s identity and grants permission to access their resources.
4. Service provider redirects the User back to Consumer, notifying it of success or failure. This request includes an authorization code (token) on success.
5. Consumer makes an out-of-band request to the service provider and exchanges the authorization code for an access token which is used as an authorization method in the future.

OAuth used by internet service companies

Below table may be outdated. The current modern companies are migrating into OAuth 2.

Internet Service Companies	OAuth Version
Facebook	2.0
Foursquare	2.0
Google	2.0
Microsoft (Hotmail, Messenger, Xbox)	2.0
LinkedIn	2.0
Daum (Tistory)	2.0
NHN (Open API)	1.0a
Daum (Yozm, Open API)	1.0a
MySpace	1.0a
Flickr	1.0a
Bitbucket	1.0a
Twitter	1.0a
Vimeo	1.0a
Yahoo!	1.0a
Dropbox	1.0

OAuth 1.0

OAuth 1.0 Protocol is defined by RFC 5849. It is sometimes referred to as 3-Legged OAuth due to the number of requests between the provider and consumer. It has been found vulnerable to session fixation. Recommended uses are OAuth 1.0a or OAuth 2.0.

To enable an OAuth provider, you should add a Service Provider record with the necessary request_token_url, authorization_url and access_token_url as defined by the protocol. Service provider’s API documentation should detail these for you. You will also need to define a profile_url which is the API endpoint for requesting the currently authenticated user’s profile information. You will also need to register for a key/secret pair from the service provider.

This protocol is implemented by a number of providers. These providers include Twitter, Netflix, Yahoo, Flickr, Bitbucket, and Dropbox. Additional providers can be found on the OAuth.net Wiki.

OAuth 2.0

Unlike OAuth 1.0, OAuth 2.0 is only a working draft and not an official standard. In many ways, it is much simpler than its predecessor. It is often referred to as 2-Legged OAuth because it removes the need for the request token step.

To enable an OAuth provider, you should add a Provider record with the necessary authorization_url and access_token_url as defined by the protocol. The provider’s API documentation should detail these for you. You will also need to define a profile_url which is the API endpoint for requesting the currently authenticated user’s profile information. You will also need to register for a key/secret pair from the provider.

OAuth 2.0 relies on HTTPS for security and is currently used and implemented by APIs from companies such as Facebook, Google, Twitter, and Microsoft. OAuth1.0a is more difficult to use because it requires the use of cryptographic libraries for digital signatures. However, since OAuth1.0a does not rely on HTTPS for security it can be more suited for higher risk transactions. I wouldn’t recommend using OAuth 2.0 for handling sensitive data. It is pretty much secured by HTTPS protocol.

---